The present invention relates to a memory management technique. In particular, the present invention relates to management of objects stored in a memory in a language processing system.
As one of causes of the problem that an application program does not exhibit anticipated execution performance, a memory leak can be mentioned. The memory leak is a phenomenon that a memory area allocated during execution of the application program is not released by some reason even after it has become unnecessary and consequently the amount of memory used by the application program continues to increase.
If the memory leak advances, available empty memory areas gradually decrease and a memory area having an amount required for program execution cannot be allocated in some cases. If it becomes impossible to allocate a memory area having an amount required for program execution, execution of the application program or the whole of the system including the application program terminates abnormally. In this way, the memory leak is one of causes of lowering in the solidity of the application program.
From the viewpoint of language specifications, causes of the problem that a memory area that has become unnecessary is not released can be broadly classified into two categories. One of them is caused by that a memory area is not released suitably in a program language a programmer needs to explicitly specify release handling of a memory area (for example, the C language). The other of them is caused by that a memory area is not released in a program language (for example, the Java language (“Java” is a trade mark, the same holds true in the ensuing description) in which a language processing system implicitly releases a used memory area.
In an application program generated using the former cited language, the memory leak occurs when release handling of a memory area is neglected. Also when a pointer to a memory area in use is rewritten during execution of the application program, the memory leak occurs in some cases.
As a technique for detecting occurrence of such a memory leak, for example, a technique disclosed in U.S. Pat. No. 5,689,707 is known. According to the technique disclosed in U.S. Pat. No. 5,689,707, when allocating a memory area, allocation information including an expiration event which indicates an event for which the memory area should be released and a dependent pointer is recorded in a memory allocation table, besides a file name and a line number. When checking a memory leak, a memory area that is not released even after the expiration event has been terminated is detected.
In the latter cited language such as, for example, the Java language, a memory area (object) that has become unnecessary is collected by garbage collection (hereafter referred to as “GC” mechanism) (see Richard Jones and another, “Garbage Collection,” John Wiley & Sons, pp. 25-28). The expression “collecting an object” means releasing a memory area in which the object is stored.
In the mark•sweep scheme which is a typical scheme of the GC mechanism, objects that are in the reference relation are marked to indicate that the objects are necessary objects, and thereafter objects that are not marked are collected as unnecessary objects. In the Java language, therefore, explicit release of a memory area in a program is not needed. Even if a programmer neglects the release handling of the memory area, therefore, the memory leak does not occur.
In the mark•sweep scheme, however, objects that are in the reference relation are not collected even if the objects become unnecessary to a user. If there is a reference relation, therefore, the object is not collected even if the object is unnecessary and a memory leak occurs in some cases. In the case of a language in which explicit release of a memory area is not needed, it is extremely difficult to discriminate unnecessary objects from among objects that are in the reference relation.
As a technique for detecting a place where such a memory leak has occurred, a technique of totalizing and investigating memory use quantities of objects every class and detecting objects in a class in which the memory amount used tends to increase as objects suspected of being involved in a memory leak (hereafter referred to as leak objects) is disclosed (see JP-A-2002-108698).
According to the technique disclosed in JP-A-2002-108698, alarm time and maximum survival time for a allocated memory are managed and the user is urged to release a memory area that is not released although the alarm time is expired. And a memory area that is not released although the maximum survival time is expired is released by a memory management mechanism.
In an application program developed by using a program language in which a memory area is released by the GC mechanism, the technique disclosed in U.S. Pat. No. 5,689,707 cannot be applied and it is difficult to detect unnecessary objects from among objects that are in the reference relation by taking an object as the unit.
Furthermore, although it is possible to detect objects having a high possibility of being an unnecessary object from among objects that are in the reference relation, there is a fear that the execution performance of the application program will be degraded because of a heavy execution load of detection processing.
On the other hand, in the conventional technique disclosed in JP-A-2002-108698, coping with a memory leak is delayed if the maximum survival time is set to be long. If the maximum survival time is set to be short, there is a fear that an application program will not operate normally because a necessary object is collected sometimes.
In addition, in a situation where a memory leak occurs, a large amount of unnecessary objects are stored. If the user is caused to make a decision on collection of leak objects, therefore, the burden on the user becomes heavy and it is not realistic.